MJ-16: The compressed direct-write path emitted generic {0xFF, 0xFF} error
frames, so a failing command was unidentifiable. The published spec says error
frames are 0xFF followed by the command code ({0xFF, cmd}). Make the firmware
conform by setting the second byte to the failing command's low byte, matching
the existing {0xFF, 0x72} gray4 END frame.

Sites (src/display_service.cpp):
- handleDirectWriteCompressedData length-overflow guard -> {0xFF, 0x71} (DATA)
- handleDirectWriteCompressedData zlib-stream failure    -> {0xFF, 0x71} (DATA)
- handleDirectWriteStart decompressed-size mismatch      -> {0xFF, 0x70} (START)
- handleDirectWriteStart initial zlib-stream failure     -> {0xFF, 0x70} (START)
- handlePartialWriteStart zero logical-size guard        -> {0xFF, 0x76} (PARTIAL START)
- handleDirectWriteEnd compressed final-flush failure    -> {0xFF, 0x72} (END)

Backward-compatible with updated clients: py-opendisplay PR #120's
is_compressed_failure_frame() accepts both {0xFF, 0xFF} and {0xFF, 0x70} for the
compressed-START fallback, and the website direct-write handler (PR #28) treats
any leading-0xFF frame as an error.


Claude-Session: https://claude.ai/code/session_012g2e8mr132vcizx92WsgiR

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>